I have been involved in project with a demand of sophisticated GUI as front-end.
The GUI applet utilized dynamic data, graphs, charts, interactive graphical topology, and complex trees. A decision about server was made according to simple logic: if applet is Java - server also must understand Java, if so, the best of Java enterprise is J2EE that includes EJB, JMS, etc.

I evaluated several EJB Servers. In most cases I just slightly changed a client side and the deployment descriptor of enterprise beans and they begun working. Also very often, I had to create stubs.

It was always pleasant to see how my beans work on different server. I tested the servers on LAN and even on the single machine. In this situation, you would not care about such things as communication, firewalls, fail-over and performance. You have almost ideal environment when you think only about business logic implementation.

I faced with real problem when I tried to get J2EE applet working with EJB Server on Internet.

An obvious demand was HTTP Tunneling. All tested servers had theirs own unique implementations (or sometimes none) of HTTP Tunneling. In most cases the implementation prohibited callbacks or asynchronous communication. Each of the tunnels had different or even no implementation of timeouts, fail-over, performance, etc. Each tunnel had its own demands for server-side web interface. In most cases, it had to be special appropriate vendor-specific gate or web server. Usually developer could not get a clue how the tunneling works and how he can customize or override its behavior.

How can you get everything working through your favorite web-server? And if you need to utilize JMS or CORBA, how would you get them working through same tunnel? Or maybe you want to use XML or SOAP for data marshalling. How would you do it the same generic way for the different EJB Servers? And how would you deal with asynchronous staff? In addition, it would be great if client-side communication library had the small size without needs being signed. Moreover, sometimes it would be nice to have J2EE applet working in Internet Explorer without Sun's Java Plug-in.

I discovered for myself that there is no generic way to handle communication for J2EE. Everything was provider-oriented. Moving from one EJB Server to another was indeed not that easy as it seemed. In the situation before beginning of development you have to certainly choose a provider of the EJB Server and stack on it.

The purpose of JProxy is to make client communication with J2EE services portable and customizable. JProxy is a thin customizable layer for access distributed services and objects from Java. The layer may be applied for such APIs as CORBA, EJB, RMI, JMS, JNDI. It encapsulates provider's specifics of distributed services. It also allows customization of distributed object access in order to achieve better performance, fail-over, and scalability. HTTP Tunneling is one of application of the idea.